Steve Kemp wrote an irssi script and accompanying utility to show facelets corresponding to IRC users, following an idea earlier mentioned by Lars Wizenius ,less than 5 hours earlier. Wow, that certainly is a neat thing. There is one problem for me though: My Debian login is “sven”, while my usual IRC nick (oh well, since I’m actually rarely on IRC, speaking of “usual” is perhaps wrong) is “incase”, since the “sven” nick was already taken on both freenode and oftc. Any idea how to work around that?

Pointed at the issues by Josselin Mouette’s post, I got aware of a list of issues posted by JP Rosevear, which is a reply to Mark Shuttleworths post to the opensuse mailinglist. Note especially point 2, which is: “Preventing the Debian GNOME maintainer from updating GNOME packages until after Ubuntu LSO had shipped because you had hired him.” If this issue is true, it’s the worst thing I ever heard of regarding Canonical. I mean it’s bad enough that points 1 (“Having a stated policy of not funding any significant new software development because the Return on Investment is not good enough”) and 3 (“Not releasing any source code for launchpad/rosetta/malone to maintain a competitive advantage”) certainly are true (even though I can’t prove and therefor don’t 100% believe the second part of #3). But unless there is a very good reason to delay the submission of the patches developed to “upstream”, Debian.
It’s bad enough that Canonical hired the most active Debian Developers, depriving Debian of much of their time, while not really supporting Debian (i.e. while not actively submitting patches to Debian). It would have been better for the community if Canonical had hired less active DDs (or even non-DDs). Sure it would have been harder to select some sufficiently qualified people for the jobs, but the total outcome whould have been better IMHO (getting time from previously uninvolved people, while keeping the existing contributors). Anyway, I really would like to know wether the mentioned point #2 is true, and if so wether any valid reason for doing so could be given before I set my opinion about this issue in stone. One thing is sure however, I’m becoming more and more critical regarding Ubuntu and Canonical over time while I once hoped that the opposite would become true for those criticizing Canonical at that time. Actually I still hope so (and thus I hope reason to become less sceptical again).
Another thing is also sure: If Canonical wants to use Debian as a base for much longer, it should make damned sure to work with Debian more actively instead of seemingly working against it (more or less openly). Update: As also pointed out in a comment below, a post by Scott James Remnant proves point 1 from the the aforementioned list and gives a further hint that point 3 might be true. More precisely it says “we have a policy of not doing our own software development, but only packaging what others have developed”, which probably means “not doing our own major software development”, since - as a comment to that post also says - Canonical did some software development, like launchpad/rosetta/malone and some other relatively small projects.

Enrico said in live-cd-on-removable-disk: Mostly it boils down to running the xorg-creation script at every boot time. There are various tools to do that. Some are here, but there is surely more. (Enrico’s note: do we have anything in Debian that we can install and just does that?)
Well, Enrico, a tool I really grew fond of, which auto-configures X on Debian systems is xdebconfigurator, it lacks being auto-run on each system start, which I consider a feature on normal systems, but for your proposed usage (i.e. a portable USB-storage based Debian system), it would certainly be the right thing. Essentially, it never failed on me. Except for VMware virtual machines, where all it did wrong was that it proposed too high resolutions which resulted from my dual-screen Windows setup I ran VMware on. You might want to give it a try.

Eric has asked: Why is video conferencing so hard? Actually, I would extend that: Why is SIP so hard? It’s far from being easy to find suitable SIP clients which support chat, voice calls and preferably also video calls. Preferably, I would obviously like to find versions of the same client for different operating systems, but I would actually accept any sufficiently stable clients. Currently, my research is focussed on a Windows client, but I will soon also need one for Linux. As of now, the client closest to what I would like seems to be CounterPath’s eyebeam/X-Lite, which supports chat, voice and video, including proper presence support, but it has several problems, the most annoying ones being a nice “little” memory leak (going from 50MB total size to 350MB total size within a few days without much SIP activity) and the fact that it sometimes uses up 100% CPU while putting itself to high priority, which makes it almost impossible to recover from this without a hardware reset. I’m glad WengoPhone went GPL[*] for their 2.0 version. From what I saw, WengoPhone is quite promissing and the fact that it is now opensource makes it much more likely that it evolves quickly into a stable, portable and usable platform for SIP telephony. Anyway, if someone knows good SIP clients, which support at least voice and IM/chat and run on Windows or Linux (preferably both), I would surely be interested. [*] In case anyone wonders like I did: the source for the WengoPhone 2.0 pre-releases/release candidates is available only via a subversion checkout as described in their wiki.

Steinar H. Gunderson wrote about CDBS once again, and I couldn’t agree more. CDBS introduces a lot of complexity for non-trivial packages, and it especially is basically undocumented. So what is CDBS’s value? For non-trivial packages, it is hard to use, since you basically need to decipher the CDBS code. For trivial packages however, it doesn’t add much value over dh_make. That’s actually sad: I like the general idea behind CDBS, but it is implemented badly IMHO. What it should do, if implemented right is to automate anything you want done on an easy package while providing and documenting (which includes consistently named hooks and options) all the interfaces needed to maintain non-trivial packages. Ideally, this would even include packages which need multiple build runs (like providing two differently configured versions of the same binary in two packages). But as said: It would need consistent names and proper documentation, and CDBS fails both currently. I however hope this improves in the future. Don’t ask me to work on this however, since personally, I’m quite happy using debhelper on my packages, since it is removing complexity (not typing work or lines of code) from debian/rules while keeping it obvious from that file what is done during a build. I would really like to see the reasoning from Erich on why he thinks CDBS is NMU-friendly, since I don’t get why he thinks so from his blog post.

I’m trying to set up a laptop which needs as much security and privacy as I can get. It turns out the main problem is that I want and need dual-boot: Windows XP Professional and Linux (Debian Etch). Now, Encrypting of all partitions used (except /boot of the Debian installation) is a must. Without dual-boot, this won’t be any problem, but not with the wish to dual-boot. The Linux side isn’t a real problem, I simply use a dm-crypt’ed partition as the only “physical” volume in an LVM volume group, which contains three logical volumes: Swap, / and /home. This means I only need to enter my LUKS/dm-crypt password once during boot. Shared partitions (shared between Windows and Linux) are also encrypted with dm-crypt/LUKS and decrypted by FreeOTFE (which is a really nice little OpenSource tool BTW), formatted as FAT32. The Windows side on its own won’t be too much of a problem either, since BestCrypt, PGP Whole Disk Encryption as well as DriveCrypt PlusPack (this probably isn’t a complete list) allow encryption of the Windows boot partition, but at least the latter two need their pre-boot authentication part (which is needed to be able to decrypt the Windows boot partition) to be installed into the MBR. Now, I wasn’t yet able to get Linux installed to the disk without breaking the Windows decryption. If anyone knows a program which allows encryption of the Windows boot partition and dual-booting into Linux, I would welcome a hint. Preferably, this solution should use grub as the primary boot manager.

Today at work, I wondered about xfs, which logged the following warnings via syslog: xfs xfs: ignoring font path element /usr/lib/X11/fonts/cyrillic/ (unreadable)
xfs xfs: ignoring font path element /usr/lib/X11/fonts/CID (unreadable) After investigation, I found them to be configured in /etc/X11/fs/config, which look sane even though those paths don’t exist. However, searching through all the Debian packages available to my system (which include several non-free repositories), I was only able to find one package providing fonts in …/fonts/cyrillic, but none providing fonts in …/fonts/CID. I would be interested to know why that path was included in the default search path for xfs. Not even the evil msttcorefonts package installs any fonts in that path. Could anyone refer to anything that uses (or used) that path? Granted, x-ttcidfont-conf refers to CID fonts, but no other package seems to mention them, so why is that path in the default config? I admit I’m quite puzzled.

Interestingly, Simon Richter write about rerunning maintainer scripts for changes in related packages just when I thought that it would really be nice to get SpamPD (a SMTP-proxy in Perl which scans mails for spam using the Mail::SpamAssassin Perl module) restarted when SpamAssassin gets updated. Or to get spamd (which is part of SpamAssassin) restarted when a plugin is updated, removed or installed. Of course the second one is easier since the plugin package “knows” that SpamAssassin is affected by the change and can thus reload/restart spamd.
One idea I had for this is to create a hierarchy to which an admin or maintainer could add scripts (effectively providing hooks), like this:
/var/lib/dpkg/hooks/<package>/(removal update install)/(pre post)/<hook-package>
Where <hook-package> would be the package installing the hook while <package> is the package for which the action is to be “monitored”.So that I as the SpamPD maintainer could make the spampd package install a script in
/var/lib/dpkg/hooks/spamassassin/update/post/spampd which would get called whenever spamassassin is updated, after the update, to be exact.
An alternative on per-package basis would of course be:
/var/lib/<package>/hooks/(pre post)inst/<hook-package> or /var/lib/spamassassin/hooks/postinst/spampd for the above example. I would be quite intested to hear what other devs think about this.

In Scotts Blog : Teardown,Scott had a small post about what Teardown in Ubuntu does (or did?). I like the idea that’s behind this “project”. Basically, it tries to avoid calling init scripts with “stop” when actually shutting down the system. This is feasable wherever the init script does nothing but sending the TERM signal to the associated daemon anyway. Or to put it the other way around: The only init scripts which should get called in rc[06].d (i.e. on halt or reboot) are those that do more than just TERMinating the daemon.
This is an interesting “new” approach which I personally would like to see implemented in Debian, too. The way this is supposed to get implemented in Ubuntu looks quite sane to me, too.

Well, this really is a controversal topic to say the least. While having the RMs get paid to get Etch out might be a good thing, the big problem I see with dunctank is that it is initiated by people very prominent inside Debian and moreover by people perceived as friends of th RMs in question. Though dunctank says that is distinct from Debian, due to the high profile the people involved have inside the Debian community, this distinction might not be recognized by less careful observers. The second problem is that the payment the RMs get is not connected to well specified tasks, but they are for “working on the release of Debian “Etch”. And finally, there is the problem that this is said to be an experiment. However, a good experiment has well defined objectives and well defined boundary conditions. In other words: Regarding Dunc-Tank, it is unclear to me what the experiment is trying to achieve. I admit I voted as much in favor of the experiment as the GR allowed, but in the meantime, I regret doing so. My vote was because my impression was that Dunc-Tank would pay just enough to pay rent, food and the other usual expenses (insurances, debts etc.). But now each of the two RMs is supposed to receive 6k$. This surely is less than they could earn working as IT freelancers, but it sure exceeds their pure living expenses. While just covering their living expenses would be OK for me (in the sense that I could live with it, not in the sense of being happy about it), paying substantially more isn’t, but that’s just me. A DPL collecting money to pay certain DDs is always going to ask for trouble. Or as Ben collins put it back in 2001:
… use Debian money to pay developers. It can never be done fairly, or in a way so as not to piss someone off. It will always be susceptible to political gains and/or favoritism. This subject caused a lot of hatred, and in my opinion, the experiment is a failure. Though it might help to get Etch out in time, it caused many DDs to cut down on the time they spend on Debian, among them people like the DWN editor, who used to invest a lot of time. And this effect will not go away when Etch is released and is thus hurting Debian in the long run. The whole thing might have been a lot different if some random, mostly unknown DD (or even better: non-DD) had started dunc-tank, collecting money and finally paying some DDs to work on some specific tasks. But the fact that the DPL started it makes it so controversial. But on the other hand, it would have been less likely that dunc-tank collected enough money to do so in that case. Honestly, if I were to decide, I would drop dunc-tank completely once Etch has been released (it’s too late to do it now, it would just deprive Debian of the benefits and still cause all the negative side effects). The people who thought (and think) dunc-tank was a good idea could then restart it later under some different name and without involvement of the DPL. There is only one position in Debian I could see reasons why the person occupying it should receive some sort of compensation: The DPL. The reason I see here is that this position requires a lot of time if taken seriously. This also means that many people can’t reasonably apply for it since they would need to resign from their “real world” job.

Since I just started my blog and added it to planet.d.o, I thought I should introduce myself a little. I’m in my mid 30s (ouch), working as a sys/net admin (Linux based, mostly Debian these days) in a nice little company. I first encountered Linux back in the 1990s, before the 1.0 kernel got released. Back then, I used Slackware (which, surprisingly, seems to still be around), later switching to Mandrake. About 5 years ago, I got introduced to Debian and immediately liked it for the ease and clearness of administrating it (apt+dpkg+dselect was so much better than rpm used to be at that time). For about two years now, I’m contributing to Debian, including some involvement in the earliest pre-implementation phases of the volatile repository (mainly advocating a few ideas that actually led to it’s implementation, BTW thanks to those who did the work in the end), some small packages I maintain and involvement in some small teams. Mainly the cyrus-imapd packaging team, but also (to a much smaller degree) in the cyrus-sasl, initscripts-ng and (extremely little, since noone bothered to add me to the alioth group for it yet) the php packaging teams.
Letting computers aside, my interests are quite diverse, they range from wheelchair-basketball to books (SciFi and Fantasy mainly) and RC helicopters, among others.
More interesting posts will probably follow later.